[Previous] [Next] [Index]
[Thread]
Re: Java "security holes'
While I tend to feel that people scream overloud about "java problems",
it isn't really overrestrictive to insist that an applet only talk to
the server from which it was loaded.
EG, if the server is S, the machine on which the applet is running is A,
and the applet decides it would be a good thing to talk to some other
machine, O - then A can pass a message to S along the lines of "send
some data to O".
That way the machines an applet can access, are only those that S would
have been able to access, anyway. Even if O is behind a firewall,
nothing is given away.
Then again, if you _want_ to be able to access O, and it's behind a
firewall, you need a copy of that applet on a server behind your
firewall...
...which puts http proxies in an interesting light, if they're behind a
firewall.
IMO, java technology has outpaced IP's (and DNS's) ability to keep pace.
Dana Hudes wrote:
>
> I am new to Java. I understand some folks are afraid of the ability to
> have a d/l applet proceed to contact any host on the net . BUt applets
> cannot access local files. The Java concept is the diskless workstation
> which has Netscape or other Java browser in EEPROM (along with an O/S and
> network stack, which of course does not have to be TCP/IP as long as
> sockets are supported) and maybe an Object Request Broker in there as well
> (a few meg of EEPROM all told!).
>
> Restricting outgoing connections (or incoming!) to the server you got the
> applet from is a heavy restriction of utility to the legitimate applets.
> You prohibit two stations on the net from talking, you eliminate data
> sharing between peers. One cannot have a multiplayer game. One cannot
> contact a certificate server . One cannot access a database server that
> is different from the web server.
>
> The most secure environment is disconnected from the outside world.
> THa'ts the line you're headed down.
Follow-Ups:
References: